1. Field of the Invention
Example embodiments of the present invention relate generally to methods of simulating vulnerability, and, more particularly, to methods of analyzing simulating system and/or multi-system vulnerability.
2. Description of the Related Art
Multi-stage attacks are often the most effective way for an attacker to compromise a system. Multi-stage attacks refer to a vulnerability exploitation where an attacker navigates from an initial state to a goal state by exploiting a series of vulnerabilities. An attack chain is the set of vulnerabilities that, when acted upon sequentially, compromise a system.
The simplest attack chain is a single exploit of a vulnerability that results in a transition to the attacker's goal state. For example, if an attacker is directly connected to a target system, the attacker merely has to compromise the defenses of the target system to achieve the goal state, which is root or administrative privileges on the target system. In a further example, entering an administrator password onto a computer running a Windows Operating System (OS) may demonstrate a single step where an attacker may directly transition to the goal state.
Often, however, in order to reach the goal state, more than one vulnerability must be exploited, and thus an attack chain will typically contain a series of “chained” attacks. Furthermore, even if the goal state is reachable through a single attack, a chain of attacks is likely to make the intrusion stealthier because of difficulties for security systems to piece together the different vulnerability exploitations so as to recognize the attacker's true target, or in some cases, to even recognize that the multiple exploitations constitute an attack.
Modern computer systems typically contain many applications and services, many of which are enabled by default. These services may be secure in isolation but their integration and/or interaction can often provide a pathway for an opportunistic attacker. Further, one of the principles of network design is separation of services. The “separation of services” design criteria often result in separate systems providing different services. For example, a first system may provide a file transfer protocol (FTP) service and a second system may provide a mail or Simple Mail Transfer Protocol (SMTP) service.
Aside from partitioning complex organizational systems by services, the services themselves may be further partitioned based on the security level granted to the service user. Users are granted “user-level” privileges, allowing the use of a service in a predefined and controlled manner. However, applications and operating systems also have higher privileged accounts, typically referred to as “admin” or “root”, which grant users the ability to modify or configure software in wide-ranging ways. In an example, “admin-level” or “root-level” privileges grant users complete control to operate of a service application or operating system. However, it is understood that the a set of possible privilege-levels is not limited to no privileges, user-level privileges or root-level privileges. Rather, additional privilege levels, for example, associated with privileges greater than user-level but less than root-level, may be granted by a system. For example, a web server may run at a higher privilege level than user-level to facilitate script execution, but at a lower privilege level than root-level to protect the web server from a malicious attack. In another example, an account for a backup operator may grant sufficient privileges to read critical system files, but not to have overwrite or replace such files.
Another well-known concept is that of separate domains or zones within an organization's infrastructure. Many organizations have services for distribution to the general public, as well as separate “internal” services and systems for distribution only to authorized agents of the organization (e.g., a network administrator, etc.). The partitioning of zones to separate such services typically causes at least two zones to be employed within the organization's network. The semi-public or demilitarized zone (DMZ) is an area where an organization will deploy services that are to be accessible from a public zone or Internet. A private zone is where information, systems, and services reside within the organization.
FIG. 1 illustrates a conventional network 100. As shown in FIG. 1, an attacker is positioned within a public zone 20 (e.g., an Internet location). Assume the attacker 10 wishes to infiltrate a target system 55 within a private zone 60 of the network 100. From the perspective of the attacker 10, it will be difficult to directly interact with the target system 55 because the attacker 10 must traverse a DMZ 40, as well as two firewalls 12 and 14. However, the DMZ 40 is typically configured to grant services to users residing within the public zone 20. Accordingly, the attacker 10 may choose to indirectly attack the target system 55 by first breaching the DMZ 40, and then using the attacker's advantageous position within the DMZ 40 to breach the private zone 60. While the attacker 10 may still have difficulty in breaching the security of the private zone 60 from the DMZ 40, the attacker 10 will typically have more success attacking from the DMZ 40 as compared to an attack initiated from the public zone 20.
Even the most simplistic network used by an organization is likely to have at least one router or firewall performing some type of traffic filtering. Accordingly, from the attacker's perspective, it is typically beneficial to use multiple intermediary hosts in route to the ultimate target.
Further, breaking up attacks on targets into a plurality of attacks on intermediate hosts, which eventually lead to the target, can be beneficial for other reasons aside from simply making a potential attack more likely to succeed. For example, a basic offensive strategy in most adversarial situations, both within the context of computer hacking as well as physical reconnaissance, is to inflict harm (e.g., such as data capture) on an enemy without being detected and without having the attacker's actions traceable back to their true origin. In other words, attackers often favor stealth and lack of traceability, even if such considerations lessen the potential harm, over more crippling and yet easily traceable attacks.
Accordingly, an attacker using intermediate hosts increases the difficulty in tracing an attack back to the attacker's origin. Also, if the final intermediary host (e.g., the last device compromised before the target) and the target machine have a “trust” relationship, the attack may be difficult to detect. Thus, even if the target can be directly attacked by the attacker, the attacker may still have incentives for employing a multi-stage attack.
Attack graph generation and analysis is a common tool used to assess system vulnerability. A conventional attack graph includes all possible attack chains for a given system. Attack graphs provide a visual means of analyzing the multiple pathways (i.e., attack chains) to a given goal state. Attack graphs can be used in many domains of information security, from vulnerability assessment and network design to intrusion detection and forensics.
However, attack graphs are typically generated using a labor-intensive process which involves experts analyzing system characteristics (e.g., by analyzing application documentation, source code of operation systems for open-source systems, running diagnostic test software to detect vulnerabilities, etc.) to ascertain vulnerabilities. Thus, analyzing multi-stage attacks with conventional attack graph methodologies increases the labor required exponentially because attack graphs for each system must be generated and then compared/combined to trace an attacker's potential paths to a target. As such, using conventional attack graph generation techniques to generate attack graphs for multi-stage attacks is not practical given that it is a labor-intensive and time-consuming process.